home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Night Owl 9
/
Night Owl CD-ROM (NOPV9) (Night Owl Publisher) (1993).ISO
/
038a
/
inthlp2.zip
/
INTHLP2.DOC
Wrap
Text File
|
1993-04-21
|
34KB
|
646 lines
The following is correspondence in response to my posting of
INTHLP.ZIP (INTHLP.DOC) to UseNet comp.sys.dcoms.modems
For Columbia Kermit Users:
_______________________________________________________________________
***********************************************************************
from Dr. W. Curtiss Priest
Center for Information, Technology and Society
Lexington, MA 02173
Internet: bmslib@mitvma.mit.edu
Voice: 617-862-7763
_______________________________________________________________________
***********************************************************************
Received: from MITVMA by MITVMA.MIT.EDU (Mailer R2.10 ptf000) with BSMTP id
0419; Sun, 18 Apr 93 13:48:36 EDT
Received: from watsun.cc.columbia.edu by mitvma.mit.edu (IBM VM SMTP V2R2)
with TCP; Sun, 18 Apr 93 13:48:32 EDT
Received: by watsun.cc.columbia.edu (5.59/FCB/jba)
id AA02377; Sun, 18 Apr 93 13:48:26 EDT
Date: Sun, 18 Apr 93 13:48:25 EDT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
To: bmslib@mitvma.mit.edu
Subject: IRQs, etc.
Message-Id: <CMM.0.90.4.735155305.fdc@watsun.cc.columbia.edu>
Hi. Loved your article. Did you see mine? We ought to put our heads
together and come up with a universal compendium on this. Here's what
I wrote for Kermit users a few months ago ... (and didn't say nearly
enough -- e.g. avoided mentioning products [or Rockwell chipsets] by
name for fear of lawsuits...) - Frank
_______________________________________________________________________
***********************************************************************
TROUBLESHOOTING MS-DOS KERMIT SERIAL PORT AND MODEM PROBLEMS
"Why can't MS-DOS Kermit find my COM3 or COM4 port?"
"Why can Kermit send characters to my COM port, but not read them?"
"Why doesn't Kermit work with my internal modem?"
First, rule out the obvious: Is everything connected and turned on? Did you
give a SET PORT command for the right device, and did you give it BEFORE any
other device-related commands, such as SET SPEED and SET PARITY? Remember,
port-related settings apply to the port that was selected in the most recent
SET PORT command, so a proper sequence would be, for example:
SET PORT COM2 ; First select the port you want to use.
SET SPEED 19200 ; Then set the desired speed on the selected port,
SET PARITY EVEN ; and other parameters for this port, such as parity,
SET FLOW RTS/CTS ; flow control,
SET LOCAL-ECHO OFF ; and CONNECT-mode echoing.
Each of these parameters is remembered for each port, so switching ports (e.g.
SET PORT COM1 after you have given the above sequence of commands) switches
all of these parameters to their previous (or default) values for the port you
have switched to.
To see the current port-related parameters, type the MS-DOS Kermit command:
SHOW COMMUNICATIONS
This displays all the relevant information about your currently selected
communication device, which is COM1 by default. Check the settings carefully
to be sure they are what you intended.
* * * *
The following discussion, which applies to MS-DOS Kermit versions 3.11 and
3.12, is detailed and technical, but most of it boils down to (a) installing
a patch; (b) telling Kermit two numbers, the port address and IRQ value; and
(c) fiddling with your modem. Keep that in mind as you read more about PC
hardware than you ever wanted to know.
HOW A PHYSICAL COMMUNICATION PORT IS ASSOCIATED WITH A DOS COMn DEVICE
DOS PCs come with full support for two communication ports, COM1 and COM2, but
with provisions for at least two more, COM3 and COM4. The basic problem with
COM3 and COM4 is that they are not well (or consistently) supported in most
types of PCs, as are COM1 and COM2 which rarely (by themselves) cause any
problems. This discussion considers only COM1-COM4, since higher-numbered COM
ports are rare, and in any case are not presently supported by MS-DOS Kermit.
The digit in the port name is an index into an area in memory that contains
the address of the serial port hardware. The BIOS (the PC's Basic Input/Ouput
System) has four words reserved starting at segment 40 (hexadecimal), word 0,
to hold the addresses of the first four COM ports. Word 0 defines COM1, word
2 (two bytes per word) defines COM2, word 4 COM3, and word 6 COM4. To view
these addresses:
C:\> debug (start the debug program)
-d 40:0 (display segment 40)
-q (quit the debug program)
("C:\>" is the DOS prompt, "-" is the debug prompt.) Here are the results
of this operation on a PS/2 with 3 COM ports:
0040:0000 F8 03 F8 02 20 32 00 00-BC 03 00 00 00 00 60 03 .... 2........`.
0040:0010 65 46 00 80 02 00 00 20-00 00 38 00 38 00 3E 34 eF..... ..8.8.>4
0040:0020 20 39 78 2D 2E 34 78 2D-0D 1C 64 20 20 39 34 05 9x-.4x-..d 94.
0040:0030 30 0B 3A 27 30 0B 0D 1C-75 16 67 22 20 39 00 00 0.:'0...u.g" 9..
0040:0040 0A 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00 ..........P.....
0040:0050 00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0040:0060 0E 0D 00 D4 03 29 22 76-07 35 18 FF F9 C8 0F 00 .....)"v.5......
0040:0070 00 00 34 12 00 01 00 00-14 14 14 20 01 01 01 01 ..4........ ....
The first line contains the COM port information (ignore the other lines, as
well as the funny characters on the right). "F8 03" is the 2-byte COM1
address, expressed in hexadecimal (base 16) with the low byte shown first.
Thus the actual COM1 address is 03F8 hex, which is expressed in Kermit
commands as \x03f8. The COM2 address is 02F8, the COM3 address is 3220, and
(since there is no COM4) the COM4 address is 0000. That is how both DOS and
the BIOS (and hence many communication programs, including Kermit) understand
which ports are defined, and where to find them.
When your PC is powered up, the BIOS startup code checks for serial port
hardware (that is, a Universal Asynchronous Receiver/Transmitter, or UART) at
the two port addresses 03F8 and 02F8. If it finds a UART at the first address
then that address is placed in word 40:0 and declared to be COM1. Then the
BIOS tries the second address and if successful this address goes into the
first available word at that time, typically 40:2 as the address of COM2.
Thus if you remove a COM1 device then a previously COM2 device will appear in
the COM1 Bios storage area and become COM1 to DOS and Kermit. What happens to
the other two words depends on the PC model and BIOS. The IBM PS/2 BIOS fills
in all four words on startup, but most others (there are exceptions) handle
only the first two because that's how IBM did it with the original PCs.
So... just setting switches or jumpers on a serial port board or
internal modem does NOT define the board to be a particular COM port.
Why, then, do some communication programs work with COM3 and COM4 without any
special fiddling? The answer is that these programs ASSUME that COM3 and COM4
are found at certain addresses, even when there are no entries in segment 40,
the BIOS communication-port area. Some of these programs show you their
assumptions in a menu (and might allow you to change them), others do not.
The assumed values are usually as follows:
Port Assumed Address (hexadecimal)
COM1 03F8
COM2 02F8
COM3 03E8
COM4 02E8
NOTE: PS/2s use different addresses for COM3 and COM4 -- 3220 and 3228,
respectively, but these addresses are installed by the BIOS into segment 40
when the PS/2 is started, so well-behaved communication software (like
Kermit) will use these addresses rather than the defaults listed above.
Ill-behaved software will ignore the segment-40 addresses and erroneously
attempt to use its own values, which, with luck, might be correct but, more
likely, will not work, or at worst, can disrupt normal operation of your PC.
Unchecked use of an assumed port address is DANGEROUS if the device is not
really where the software expects, but the software goes ahead and uses the
address anyway, in particular if some other type of device, say a network
adapter, is at the given address. It can also produce unwanted conflicts
under Windows, OS/2, and DesqView, whose drivers often set the port's
segment-40 word to zero when they want to use the port exclusively and without
interference, and then restore the real address when they are done, and
similar unwanted interference with Int 14H redirectors that allow serial-port
communication software to be used on network connections.
Unlike most other PC communication software, Kermit will NOT attempt to use a
communications port unless:
(a) It finds its address in the BIOS comm-port area, segment 40, or:
(b) You specify the address yourself
AND:
The device at the given address passes certain tests, in which registers
(addresses related to the port's base address) contain certain values that
are legitimate for a UART.
In other words, KERMIT IS MORE CAREFUL than most other communication software,
because does not want to chance disrupting normal operation of (or damaging)
your PC.
SPECIFYING THE PORT ADDRESS
If you tell MS-DOS Kermit to SET PORT COMn (where n is 1, 2, 3, or 4), and
Kermit responds:
Warning, no hardware for this serial port.
This port will be operated through the BIOS as BIOSn
it means that Kermit did not find an address for the port in the BIOS area or
it did find one but the hardware at that address did not look like an IBM-PC
compatible UART. If the cause of the message is a missing address, you can
tell MS-DOS Kermit the address of the port by issuing the following command:
SET COMn \xhhhh
where n is 1, 2, 3, or 4, and hhhh are four hexadecimal digits (0-9, A-F)
representing the 16-bit address. This command not only informs Kermit of the
address, but also inserts the address into the appropriate word in segment 40
so other programs can find the port (assuming they follow the rules), and so
you don't have to give this command to Kermit again until after the next time
you reboot.
After giving the SET COMn command, give a SET PORT COMn command for the same
port. The SET COMn command must come first, then the SET PORT COMn command,
as in this example for COM3:
set com3 \x3f8 ; Specify the address of COM3
set port com3 ; Select COM3
How do you know what addresses to give? Suppose you have purchased an
internal modem or an add-on serial port and you want to install it as a
particular COM port, say COM3. The installation instructions for your device
will tell you how to do this. The device must be configured -- generally by
setting little switches or installing or removing jumpers. The manual should
tell you the address for each COM port. You have to make sure that the
address that you have configured for the device agrees with the address that
Kermit will use.
Although it is not recommended that you guess at address values, sometimes it
is the only way (as often with inherited equipment), for which occasions here
is a list of the addresses commonly used for serial ports and internal modems:
Port Likely Addresses (hexadecimal)
COM1 03F8
COM2 02F8
COM3 03E8, 3220
COM4 02E8, 3228, 02E0
It is relatively unlikely that you will find a serial port at any address not
listed above, but you might find a port at another port's expected address.
The use of these addresses in SET COMn commands should be relatively harmless
(provided you don't also specify an interrupt, explained later); if there is
no error message, Kermit found a possibly usable port. If there is an error
message, no harm should have been done.
Now let's look at the other cause for the "This port will be operated through
the BIOS" message, namely that an address was found in segment 40, but the
device at that address does not appear to be a genuine serial port. Why would
this happen? There are several possible explanations, including:
1. The device is at a different address. Check your device's configuration
again, or else your SET COMn command.
2. Your device is indeed at the given address, but its registers do not
contain values expected of a true PC serial port. In that case, BIOS
operation is the only alternative.
3. Your device is at the given address, but there is a conflict with another
device at that address or the machine's bus speed (not CPU speed) is set
so high that the hardware test gave confusing results.
When Kermit operates a port through the BIOS, rather than directly, it will
be MUCH slower and might not work at all because the BIOS requires the CD,
CTS, and DSR modem signals to be asserted by the device connected to the port
(and the CD signal is normally and by default NOT asserted by a modem before
it has made a connection to another modem). In that case, you will have to
configure the device (e.g. modem) to assert DSR, CTS, and CD always, or wire
your modem cable to fake these signals (e.g. by cross-connecting them to DTR).
Assuming you have found the right address for your COM3 or COM4 port (or
nonstandard address for COM1 or COM2), and you want these addresses to be set
correctly for Kermit at all times, even if it doesn't read its initialization
file, you can put a command like the following in your AUTOEXEC.BAT file:
set kermit=com3 \x3e8; com4 \x2e8;
If you want the addresses to be set correctly in the BIOS communications area,
so all applications (not just Kermit), can find the ports, put a line like
this in your AUTOEXEC.BAT (substituting the appropriate ports and addresses):
kermit -f nul, set com3 \x3e8, set com4 \x2e8
INTERRUPTS
"I can send characters to the modem, but I never see any on my screen."
This common complaint (often arising from the user's observation of the modem
lights and speaker), also known as "can-talk-but-not-listen syndrome",
usually means that the communication device was found at the expected address,
but Kermit's idea of its interrupt is wrong. What's an interrupt?
To achieve high-speed communication without interfering with other
applications, Kermit reads characters from a serial device using "interrupts".
Whenever a character arrives at the serial device, the device sends a signal,
called an interrupt, that may be "caught" by application software such as
Kermit, leaving the application free to do other work in the meantime without
having to constantly look at the serial port to see if any characters have
arrived (an operation called "polling", which is used by some of the other
communications programs). Communications programs that use polling are not
sensitive to interrupts being set properly and may therefore work with
improperly-configured machines where Kermit will not (unless you give it the
required information), but they also tend to take over the entire computer.
In contrast to polling programs, Kermit is normally waiting for input from the
keyboard, and is therefore idle if you are not typing and no characters are
arriving at the communication port. In multi-tasking environments such as
Windows or OS/2, this allows other applications the largest possible share of
the CPU while Kermit is running.
When a character arrives at the port, an interrupt signals Kermit to wake up
from its keyboard-wait state and read the character from the port. But Kermit
needs a way of knowing which device the interrupt came from, so it will not
erroneously read characters from the wrong one. The device is identified by
an Interrupt Request (IRQ) number, a small integer like 3 or 4. The BIOS does
not record the IRQ number used by a serial port because the BIOS uses polling
rather than interrupts for serial port input and output. Thus the
communications software has to know which IRQ to use. By convention from the
original IBM PC, COM1 uses IRQ 4 and COM2 uses IRQ 3. There is no standard
for COM3 and above, but certain conventions are normally followed:
Port PS/2 Others
COM3 IRQ3 IRQ4
COM4 IRQ3 IRQ3
WARNING: Certain serial port cards and internal modems allow
themselves to be configured with different IRQ numbers (such as 9),
even on COM1 or COM2. Check your device's installation instructions.
Some types of PCs (PS/2s, for example) allow sharing of IRQ numbers,
provided each application has its own interrupt service routine and each such
routine is built to chain interrupts properly (i.e. pass them along to other
applications if they have arrived at the wrong place). This works, for
example, with Kermit on a PS/2; you can run two copies of Kermit under
Microsoft Windows, one using COM2/IRQ3 and the other using COM3/IRQ3 (i.e. two
ports, same IRQ), both doing input and output simultaneously with no
confusion. On most types of PCs, however, IRQs can NOT be shared, and
therefore each device must have a unique IRQ number. This caution applies
especially when you have a serial mouse on IRQ 3 or 4.
Once Kermit knows the address of a COM port, it tests to see which IRQ number,
3 or 4, the device uses. This is a safe test and does not cause any modem
signaling or communication to take place. The PC architecture has a limited
range of IRQ numbers available, and so (usually) there can not be a unique IRQ
number for each serial port when there are more than two. This results in the
common limitation that no more than two serial ports can be active at once.
MS-DOS Kermit 3.12 and earlier test first for IRQ4, and then if there is no
response, IRQ3. If both tests fail, a default value is used (on PS/2s, the
default is IRQ4 for COM1 and IRQ3 for COM2-4; on others is it is IRQ4 for
COM1 and COM3, IRQ3 for COM2 and COM4). No error message is given in this
case, but "can-talk-but-not-listen syndrome" is a likely result.
Some add-on communication boards or internal modems are set up to use IRQ
numbers other than 3 or 4 in order to avoid conflicts with COM1 or COM2 and/or
to allow more than two COM ports to be active at once. But this can be
dangerous -- for example, IRQ 5 (which is sometimes used for this purpose) is
also used by the hard disk controller on the PC/XT. IRQ 7 is often used by
network boards. For this reason, Kermit does not automatically test any IRQ
numbers other than 3 or 4, and does not use any other IRQ number by default.
But it is sometimes necessary, particularly on ISA (Industry Standard
Architecture) bus machines (PC/ATs and compatibles) and earlier (such as PCs
and XTs) to use an IRQ other than 3 or 4, for example when when an internal
modem is installed as COM3 on IRQ4, and then use of COM1 prevents COM3 from
working, and vice versa. This problem can often be solved by reconfiguring
the board to use an otherwise unused unique IRQ number. Ideally this would be
a normally free IRQ such as 10 or 11, but unfortunately most communication
boards are not configurable for IRQs higher than 7. Here is a brief, and
definitely not comprehensive, guide to the low IRQ numbers (with IRQ numbers
expressed in decimal):
2 Normally available, but some video boards use it to obey an obsolete
standard for indicating vertical refresh. Adjust video board jumpers
to not do this. On 286's and above IRQ 2 is also known as IRQ 9:
same IRQ, alternate number. Windows 3.0 had difficulty with devices
using IRQ 2, but Windows 3.1 is better.
3 Normally COM2 and COM4. PS/2's use IRQ 3 for all serial ports above
COM1. IRQ3 is also a favorite "factory default" of many local area
network (LAN) adapters.
4 Normally COM1 and informally COM3 (except on PS/2s).
5 Secondary parallel port. Parallel ports are rarely interrupt-driven
(except for Novell RPRINTER users) so this wire becomes free if
you unjumper the IRQ on the parallel port board. LAN adapters are
frequently placed on IRQ 5. PC/XTs use IRQ 5 for the hard disk. Be
careful with this one.
6 Floppy disk drives. Leave it alone!
7 Primary parallel port. Remove as described for IRQ 5. Be careful,
LAN adapters are frequently placed here.
9 Alias for IRQ 2.
10 Usually free.
11 Usually free.
12 Used by the IBM bus mouse, otherwise usually free.
13 QEMM traps math coprocessor errors here, otherwise frequently free.
14 Used by hard disk on 286 and above. Leave alone!
15 Some SCSI controllers use this. Usually free.
If your communication board uses an IRQ other than 3 or 4, you will experience
the "can talk but not listen" syndrome when using Kermit. To force Kermit to
both talk AND listen to the device, you must inform Kermit of the device's IRQ
number. This is done in the SET COMn command, after the address:
SET COMn <address> <irq>
for example:
SET COM3 \x03e8 5
When you include a number (like 3, 4, 5, 6, or 7) after the port address
(separated by a space), Kermit will skip its IRQ test and use the IRQ number
you have specified when you next give a SET PORT command for that port.
PLEASE NOTE that you MUST AVOID address and IRQ conflicts; these items
MUST NOT overlap existing equipment. SERIOUS DAMAGE can result if, for
example, the IRQ number you give is the same as the one used by your
disk controller or network adapter. Incorrect operation can result if
the interrupt is in use by a less critical device, such as a mouse.
It is necessary to specify the IRQ number in either of these two situations:
1. The communication device uses an IRQ number other than 3 or 4.
2. Kermit's IRQ test interferes with Windows or a similar environment,
and therefore must be skipped.
Check your PC's configuration carefully before specifying an IRQ number.
Before starting Kermit, you can use certain public domain or commercial
utilities, such as MAPMEM, Northgate QAPLUS, Quarterdeck MFT, or the MSD
utility shipped with Windows 3.1 to get an idea of which IRQ numbers are
already in use (these utilities are, of course, not foolproof -- for example,
they can't tell what IRQs are used by programs that are not presently loaded).
If, even after establishing the device's interrupt correctly, Kermit still
fails to operate correctly (or reliably), check to see whether:
1. Some other device (such as a mouse or LAN adapter) is generating the
same interrupt.
2. Some other software (such as a mouse driver) is catching the same
interrupt.
If you find a conflict, take whatever means are at your disposal to remove it:
remove the offending device driver or TSR from your CONFIG.SYS or AUTOEXEC.BAT
file, or turn it off temporarily (e.g. with the MOUSE OFF command for certain
mouse drivers); or reconfigure one of the conflicting devices to use a
different interrupt.
PROBLEMS WITH MODEMS
"I just bought and installed an XYZ V-Dot-Everything internal modem, and
it works with <name-deleted> and <name-deleted> communication packages,
but it doesn't work with Kermit".
This has long been a common complaint about internal modems. The same
complaint is also now being heard with alarming frequency about some of the
newer external modems.
With internal modems, particularly when they are installed on COM3 or COM4,
the most common problems are:
1. Kermit does not know the modem's address, or the device is using an IRQ
number other than 3 or 4. These problems can be fixed by giving the
appropriate SET COMn command to Kermit.
2. The internal modem is installed incorrectly, with an address or IRQ that
conflicts with one already in use on your PC.
3. The internal modem does not correctly emulate a real IBM PC serial port,
and therefore fails Kermit's hardware test, and therefore can only be
used through the BIOS.
4. The device is in a laptop, notebook, or palmtop computer, and power to
the internal modem or serial port has been disabled in the CMOS setup,
or has been turned off automatically when the cover is closed or the
machine shut down.
In recent months (beginning about mid-1992) a new generation of low-cost,
high-speed modems, both internal and external, began to appear on the market.
These modems typically offer a wide range of features: V.32 and V.32bis
modulation, V.42 and MNP error correction, V.42bis and MNP data compression,
etc. Unfortunately, many of these modems suffer from bugs not found in
earlier (and usually more expensive) modems. The problems are generally
related to initialization of the modem and interaction with its command
processor. Some common complaints:
1. An internal modem does not work at all; the modem becomes nonoperational
as soon as Kermit attempts to access it. The cause has been traced to the
fact that Kermit's initialization of the modem's UART is "too fast" for
some of these new modems. (This same initialization sequence has been
used for nearly a decade with no problems, and still works on the
well-known and reputable brands of internal modems.)
2. "Kermit won't dial or respond to modem commands". The modem ignores
dialing or other commands from Kermit. Or the modem ignores commands when
Kermit's PARITY is set to a particular value, like EVEN. Or commands are
not processed correctly above a certain interface speed.
3. "I can dial successfully, and in general send characters to and through
the modem, but I never get any characters back." This looks suspiciously
like the "talk-but-not-listen" problem, but in some cases it is a bug in,
or a configuration problem with, the modem, having nothing to do with
Kermit: the modem is simply not sending any characters to the PC.
4. "After using the modem with <name-omitted> communication software, it
also works with Kermit, but it won't work with Kermit unless I run
<name-omitted> first."
5. "I can communicate in command-mode with the modem, up until I give it
an ATZ command, at which point it seems to die."
And so on. All of these are modem, not Kermit, problems. Here are some
suggestions for overcoming them:
1. Slow the UART-initialization sequence. This is accomplished by patch #11
to MS-DOS Kermit 3.11 and patch #10 to version 3.12. These patches have
been tested successfully on several of the misbehaving modems. Get the
patch file for your version of Kermit (3.11 or 3.12). The patch files are
in kermit/a/msr311.pch and kermit/a/msr312.pch on watsun.cc.columbia.edu
on the Internet, available via anonymous FTP. Rename the file to
MSKERMIT.PCH and put in the same directory as your MSKERMIT.INI file, and
start Kermit again. At the MS-Kermit> prompt, give a VERSION command to
make sure the patches were installed. If not, give a PATCH command (or,
better still, make sure that PATCH is the first command in your
MSKERMIT.INI file, and that your MSKERMIT.INI file is in your DOS PATH so
Kermit will always execute it).
2. External modems only: Check that your modem cable has wires for (at least)
the TD, RD, SG, CTS, RTS, DSR, CD, and DTR RS-232 signals. If it does
not, replace the cable with a real modem cable, or (temporarily) configure
your modem to compensate for the missing signals.
3. Read your modem manual and check your modem's configuration. Perhaps its
interface speed is locked to a different speed than the one Kermit is
using. Perhaps it is set to use hardware flow control, but Kermit is not.
Also, check its factory and/or saved settings, and under what conditions
they are restored (for example, are they restored when the PC drops DTR?).
How are you selecting saved settings -- read your modem manual about (for
example) the difference between AT&F and AT&F2. Be aware that the AT&Fn
commands might not restore all S-registers, so double check them. Be
particularly sensitive to the registers that control interface speed,
modulation technique, error correction, data compression, negotiation, and
fallback, and note that each modem maker probably uses different registers
and commands to control each of these features.
4. Try the following sequence to initialize the port (using COM3 in this
example):
SET COM3 <address> <irq> ; (if necessary)
SET PORT 3 ; Select port 3
HANGUP ; Drop DTR on port 3
SET PORT 3 ; Re-initialize port 3
5. SET PARITY NONE when talking to the modem, and then set parity to
whatever the remote host or service requires after making the connection.
(WARNING: MS-DOS Kermit might set its parity to some other value
automatically as a result of automatic parity detection during file
transfer.)
6. Ensure that your PC bus speed is 8MHz. Some PCs (not PS/2s) come with
a BIOS SETUP facility that lets you change the PC's bus speed, memory wait
states, etc. In general, it is dangerous to deviate from the defaults,
particularly from the 8MHz bus speed, which is a standard for add-on
devices, and might be required by your communication board or internal
modem.
7. Modify HAYES.SCR, or whatever dialing script you are using, to take
extraordinary measures to ensure the modem is in command mode, and to send
its initialization commands very slowly and to try them repeatedly. For
example, change "output ATQ0V1X1\13" to something like this (note: the
modem-related commands shown here are all relatively portable -- you might
also need additional modem-specific commands, such as AT&F2 to load a
particular configuration, or specific S-register settings affecting speed,
flow control, modulation, fallback, etc.):
WAIT 1 DSR ; See if modem is asserting Data Set Ready
IF FAIL FATAL -
{No DSR signal: Is your modem connected and turned on\63}
SET PARITY NONE ; Use no parity
SET COUNT 5 ; Try 5 times to initialize
:INIT
HANGUP ; Modem is connected - hang up on it.
CLEAR ; Clear Kermit's input buffer.
OUTPUT \B ; Send a BREAK.
PAUSE ; Wait a second.
OUTPUT \17 ; Send a Ctrl-Q in case modem is Xoff'd.
PAUSE 2 ; Wait two seconds.
OUTPUT + ; Send the most likely escape sequence,
OUTPUT + ; which is "+++" with at least a second of
OUTPUT + ; "silence" before and after.
PAUSE 2 ; ...
OUTPUT \13 ; Send a carriage return.
PAUSE ; Wait a second.
OUTPUT A ; Send an A.
PAUSE ; Wait another second.
OUTPUT T ; Send a T.
PAUSE ; Wait another second.
OUTPUT \13 ; Send a carriage return.
PAUSE ; Wait a second.
CLEAR ; Clear away echo and response.
OUTPUT A ; Send initialization command.
OUTPUT T ; One character at a time...
PAUSE
OUTPUT Q ; Q0 = Result codes enabled
OUTPUT 0
OUTPUT V ; V1 = Word result codes
OUTPUT 1
OUTPUT X ; X1 = Dial response level
OUTPUT 1
PAUSE
OUTPUT \13 ; Carriage return terminates the command
INPUT 3 OK ; Wait for OK response.
IF SUCCESS GOTO INITOK ; Got one.
IF COUNT GOTO INIT ; Didn't, try again.
ECHO Failure to initialize modem. ; No more tries.
STOP 1 ; Fail.
:INITOK
If this doesn't work, insert a PAUSE command after each OUTPUT command
or run the script at a lower speed.
8. Dial at a lower speed. Make your interface speed match the modulation
speed -- e.g. use 9600 for V.32, 2400 for V.22bis, etc. Turn off fancy
modem options like error correction and compression. etc etc. NOTE:
connection problems between the two modems have nothing to do with Kermit
and are beyond the scope of this document. If a modem appears to dial
correctly, gets connection tones, and then hangs up, it is undoubtedly a
problem between the two modems (involving one modem, both modems, and/or
the phone company), and indicates a modem configuration problem, a bug,
or a basic incompatibility between the calling and answering modems.
9. The ATZ problem. Diagnosis: The modem has a bug that makes it generate a
spurious interrupt whenever it is given an ATZ command. Kermit checks the
interrupt, learns there is no character waiting, and so PROPERLY chains
the interrupt back to its previous owner, the BIOS. The BIOS also sees
there is no data waiting, and so DISABLES (yes, disables) the interrupt.
Workaround: After this happens, SET PORT to some other serial device, and
then SET PORT back to the problem device -- this should turn the interrupt
back on.
10. Call your modem maker's technical support number. Ask if they have
replacement chips to fix bugs in your modem.